The methods and systems described below provide for faster troubleshooting and debugging of hardware and software systems which are implemented with processors built with associated embedded trace macrocells. The embedded trace macrocell (ETM) is a relatively recent addition to processors, and its function is to provide information regarding the processor execution (for example, step-by-step functioning in the processor) to a separate device specifically designed to communicate with the embedded trace macrocell and collect the data. The collected data is transmitted from the ETM, through a trace port and trace port connector, to a trace port analyzer and then to a computer workstation so that a system developer can view an on-screen display or printout of the step-by-step operation of the processor. By viewing the report of the processor operation, the system developer can determine if the system is operating properly, and, if not, the system developer can determine exactly what steps of the processor operation are responsible for any improper operations. The system developer can view the trace information using software referred to as a software debugger, and can use the same software to configure the trace port and otherwise interact with the processor, ETM, and trace port. Analysis of the trace information can reveal problems with software executing on the processor which can be addressed by modifying the software.
Though the methods and systems may be used with any processor with an embedded trace macrocell, they were developed and are illustrated here in reference to the ARM7, ARM9 and ARM10 families of processors which include an embedded trace macrocell. The ARM embedded trace macrocells can collect and transmit trace data from their associated processors, as well as associated run control signals (the run control signals are provided through the test controller (JTAG) to set up, initiate, and control the operation of the processor). The ETM signals include pipeline status signals (PIPESTAT) which provide a cycle-by-cycle indication of what is happening in the execution stage of the processor, a trace sync signal (TRACESYNC) which indicates the start of a group of substantive signals, and trace packet signals (TRACEPKT) which are substantive signals which provide information regarding the state of the processor (such as identifying the instruction being performed by the processor). The trace packet signals carry trace packets, and may be 4 bits, 8 bits, or 16 bits in length, although the trace packets themselves are typically 8 bits in length. For every cycle of processor operation, a full ETM trace record or message is transmitted to the trace port, and this information is processed and transmitted by an external trace port analyzer which records the transmissions, and stores them for subsequent examination by the host-based debugger (the number of records stored is limited by the size of RAM in the trace port analyzer).
The amount of information that can be displayed to the operator depends on how much memory can be used to store the trace information. Random access memory in the trace port analyzer (we will refer to it as the trace port RAM, to distinguish it from the various other memories in the system) is used for storing trace information prior to communicating the information to the workstation. The trace port RAM is typically 500,000 storage locations to 2,000,000 storage locations. Typically, the trace port RAM is limited to storing one instruction (or a portion of an instruction) per RAM location. Thus, all the trace information in the trace port RAM represents just a split second of operation for a typical embedded processor. (In an ARM processor running at 100 MHZ, over one gigabit of trace information is generated every second.) If the trace port RAM overflows, the system must discard the oldest stored trace information (operating as FIFO memory), stop the processor (referred to as overflow stalling) or discontinue tracing until the trace port RAM is emptied. This occurs even if the branching is not fully reported and full address information is not transmitted where it is redundant. The disadvantage to this system is that only very short periods of time can be reflected in the trace listing eventually presented to the system developer, so that a particular software bug can be difficult to isolate.